1. Field of the Invention
The present invention relates to communicating voice data over a packet-switched network with a telephone set for use by a human; and, in particular relates to displaying, for use by the human user of the telephone set, call history data resident in a protocol for setting up such voice communications, such as in the Session Initiation Protocol (SIP) for voice over the Internet Protocol (IP).
2. Description of the Related Art
Networks of communications devices and general-purpose computer systems connected by external communication links are well known and widely used in commerce. The networks often include one or more network devices that facilitate the passage of information between end stations, such as telephones and general purpose computing devices, which originate or receive the information. A network node is a network device or end station connected by the communication links. Information is exchanged between network nodes in discrete data packets according to one or more of many well known, new or still developing protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other based on information sent over the communication links. The protocols are effective at different layers of operation within each network node, from generating and receiving physical signals of various types, to selecting a link for transferring those signals, to the format of information indicated by those signals, to identifying which software application executing on a computer system sends or receives the information. Signaling between nodes is typically effected by exchanging special data packets called control plane data packets. Each data packet typically comprises 1] header information associated with a particular protocol, and 2] payload information that follows the header information and contains information that may be processed independently of that particular protocol. Often, the data in the payload for the particular protocol includes a header and payload for a different protocol associated with a different, usually higher layer protocol. The payload protocol is said to be encapsulated in the header protocol.
Commercial services that provide voice data communicated over a packet-switched network predominately use the Internet Protocol (IP) as the internetworking layer protocol to communicate with devices on different networks. A voice data session over IP between end stations is set up predominately using IP datagrams that include in the IP payload the Session Initiation Protocol (SIP) header and payload. The SIP header provides information about the party that originated the voice data, e.g., a caller network identifier (“caller ID”) and the called party, e.g., a target network identifier (“target ID”).
Many telephone sets, including wireless mobile telephone sets, have displays that indicate the other party engaged in the voice communications. For example, the telephone set of the called party displays the caller ID and the telephone set of the calling party displays the target ID. Many of these sets store one or more caller IDs or target IDs and allow a human user to access them immediately or at some later time (e.g., to support redial functions). While suitable for many purposes, there are an ever-growing set of circumstances in which this information is inadequate for one or the other of the calling parties, or both.
For example, a human user named Mary uses a voice over IP (VoIP) telephone set (setA) to call a second VoIP device (setB) that is used to provide technical support. The SIP header shows the target ID is setB. That set is an application that automatically routes the call to an available technician. The call is redirected to a third VoIP telephone set (setC) used by a technician named Jane. The SIP header is changed to show the new target ID is setC. After Jane and Mary converse for awhile, Mary asks a question better answered by a third party, named Paul, who uses a fourth VoIP telephone set (setD). Jane transfers the call to Paul. The SIP header is changed to show the new target ID is setD. After Mary and Paul converse, Mary determines that she has another question for Jane. However, the target ID for Jane is no longer displayed on Mary's setA, only the target ID for Paul. Paul does not know Jane's number; and his setD shows only Mary's caller ID. Mary can only call the technical support application (setB) and hope she is redirected to Jane again, an unlikely occurrence. Similarly, if Paul is interested in how Mary's call came to him, e.g., because Paul's network identity is not public, and if Mary is not forthcoming with the information, Paul is unable to determine that Jane directed the call to him. The problem is compounded if Mary's call is redirected a number of times before the current target of her call.
Based on the foregoing, there is clear need for techniques that allow end users to determine temporary targets of calls routed over IP and redirected to another target. In particular, there is a need for techniques to display the existence of temporary targets of a redirected call, or use information related to the temporary targets, or both.